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EXECUTIVE  SUMMARY 


A problem  area  that  continues  to  have  few  easy  and  too  often  even 
viable  solutions  is  that  which  encompasses  the  development  and  maintenance 
of  computer  software.  One  of  the  principal  conclusions  resulting  from 
recent  DOD-sponsored  studies  was  that  the  use  of  high  order  computer  pro- 
gramming languages  (HOL)  enhances  the  reliability  and  maintainability  of 
computer  software  as  compared  to  machine  oriented  language.  This  fact  is 
true  only  so  long  as  the  number  of  different  HOL  is  constrained  and  the  HOL 
remaining  are  carefully  controlled.  The  purpose  of  this  study  is  to  specify 
the  organization  and  functions  of  a HOL  Control  Facility  and  to  discuss  some 
of  the  issues  concerning  the  implementation  of  such  a facility  for  the  DOD 
HOL  Program.  This  study  reviews  the  results  and  current  status  of  the  DOD 
HOL  Program.  It  then  specifies  the  mission,  organization  and  functions  of 
an  HOL  control  facility.  Finally  it  discusses  implementation  issues  con- 
cerning the  establishment  of  a DOD  HOL  Control  Facility.  The  study 
concludes  that  control  facilities  are  necessary  for  all  DOD  approved  HOL, 
that  control  facilities  for  existing  DOD  approved  HOL  will  remain  separate 
* , entities  under  the  various  military  departments,  that  the  control  facility 

i for  the  new  DOD  HOL  should  be  a jointly  manned  and  supported  facility  set 

up  as  soon  as  possible,  and  that  the  facility  should  use  the  ARPANET  and 
become  part  of  the  National  Software  Works.  This  study  can  be  of  sig- 
nificant benefit  to  the  members  and  sponsors  of  the  DOD  HOL  Working  Group. 
This  work  can  serve  to  aid  and  stimulate  more  detailed  planning  for  a joint 
HOL  Control  Facility.  It  can  also  be  of  interest  to  those  personnel  in  a 
program  office  who  are  responsible  for  the  successful  acquisition  of 
I computer  software. 
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SECTION  I 


INTRODUCTION 

Purpose  of  the  Study 

If  the  sum  total  of  DOD  computer  software  acquisition  were  measured 
by  the  traditional  system  parameters  of  cost,  schedule  and  technical  | 

performance,  the  DOD  software  program  manager  would  have  been  fired  for  I 

seriously  breaching  his  thresholds  long  ago.  Costs  for  software  in  DOD  in 

i 

1973  (15)^  were  estimated  at  $3  to  $3.5  billion  annually  and  are  increasing  i 

as  a percentage  of  the  total  cost  for  computer  systems.  Software  is  too 
often  late,  causing  major  slippage  in  program  schedules.  Technically 
software  is  often  unreliable,  difficult  to  modify,  not  easily  transported 
to  other  systems  and  unresponsive  to  user  needs.  i 

This  familiar  litany  of  difficulties  with  computer  software  has  been  j 

i 

the  subject  of  much  discussion  in  both  the  commercial  world  and  within  the 

US  Government.  DOD  recognized  these  problems  and  sponsored  various  studies 

which  were  completed  in  1975.  The  Joint  Logistics  Commanders  study  (14:93), 

in  particular,  provided  findings  and  recommendations  concerning  approaches 

to  help  solve  some  of  these  problems.  One  of  their  major  findings  was: 

SR-3A  EVALUATION  OF  PROGRAMMING  LANGUAGES  AND  RECOMMENDED 
LANGUAGE  STANDARDS 

1 

Finding:  The  programming  language  selected  for  a given 

system  application  has  a significant  impact  on  the  ultimate 
reliability  of  the  software  developed.  A Higher  Order  Language 
(HOL)  enhances  reliability  over  a Machine  Oriented  Language  (MOL)  -i 


This  notation  will  be  used  throughout  the  report  for  sources  of  quo- 
tations and  major  references.  The  first  number  is  the  source  listed  in  the 
bibliography.  The  second  number,  if  used,  is  the  page  in  the  reference. 
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The  pro! iferation  of  programming  languages  (either  HOL 
or  MOL),  however,  is  a major  contributor  to  both  software 
reliability  and  maintainability  problems.  From  the  reliability 
viewpoint,  language  prol iferation  makes  the  language  learning 
process  difficult,  and  hence  leads  to  coding  errors,  discourages 
the  development  of  adequate  test  and  support  tools  around  each 
language;  and  reduces  management  visibility  and  control  over  the 
software  design  and  development  activity.  From  the  maintenance 
viewpoint,  language  proliferation  complicates  the  institutional 
control  over  language  features;  and  magnifies  the  documentation, 
training,  and  other  costs  in  proportion  to  the  number  of  languages 
-iD  iJse. 

Their  recommendations  as  a result  of  this  finding  were: 

1.  To  encourage  the  use  of  HOL  by  restricting  the  use  of  MOL. 

2.  To  discourage  the  proliferation  of  HOL  currently  being  used  in  DOD. 

3.  To  establish  control  facilities  for  DOD  authorized  HOL. 

At  the  same  time  as  the  above  study  efforts  were  nearing  completion, 
two  related  initiatives  were  begun.  The  first  was  the  establishment  of  a 
DOD  Weapons  System  Software  Management  Committee^  in  December  1974.  It  was 
to  identify  and  solve  the  problems  associated  with  weapon  system  computer 
resources  throughout  their  life  cycle.  The  aforementioned  studies  were 
major  inputs  to  this  committee.  Its  first  efforts  culminated  in  the  pub- 
lication of  a software  management  plan.  HOL  policy  actions  in  that  docu- 
ment are  summarized  in  Figure  I (3:11-4).  In  turn  a DOD  Directive  concern- 
ing the  management  of  computer  resources  in  major  defense  systems  was 
issued  in  April  1976.  A major  subparagraph  covered  HOL  (6:3).  It  stated: 


^Also  later  known  as  DOD  Software  Management  Steering  Committee  and 
finally  as  DOD  Management  Steering  Committee  for  Embedded  Computer 
Resources  (MSC-ECR). 
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Figure 


Software  Language  Standardization  and  Control.  DoD  approved 
High  Order  Programming  Languages  (HOLs),  will  be  used  to 
develop  Defense  system  software,  unless  it  is  demonstrated 
that  none  of  the  approved  HOLs  are  cost  effective  or 
technically  practical  over  the  system  life  cycle.  Each  DoD 
approved  HOL  will  be  assigned  to  a designated  control  agent 
who  will  be  responsible  for  such  activities  as  validating 
compliance  of  compiler  implementations  with  the  standard 
language  specifications,  gathering  data  as  to  the  use  of  the 
language,  and  for  disseminating  information,  compilers,  and 
tools.  The  designated  control  agent  will  also  be  responsible 
for  assuring  language  stability.  . . 

In  November  1976  a DOD  Instruction  (8)  was  published  designating  the 

current  list  of  DOD  approved  HOL  and  their  control  agents. 

The  second  initiative  was  the  establishment  by  DDR&E  of  the  DOD  High 
Order  Language  (HOL)  Working  Group  in  January  1975  (4).  Its  purpose  was 
to  determine  the  feasibility  of  establishing  a minimal  set  of  common  high 
order  programming  languages  for  use  in  major  defense  systems.  Its  thrust 
was  to  establish  HOL  requirements  and  to  determine  the  best  approach  to 
meet  these  requirements.  It  was  not  necessarily  limited  to  adoption  of  an 
existing  HOL.  Its  current  actions  indicate  a modification  to  an  existing 
HOL  will  result.  This  HOL  will  eventually  be  added  to  the  list  of  DOD 
approved  HOL  and  will  require  a control  agent. 

Whether  it  is  an  existing  approved  HOL  or  an  eventual  addition  to  the 
list,  some  type  of  control  facility  must  be  established.  How  should  a HOL 
control  facility  be  organized?  What  should  its  specific  functions  be? 
Should  there  be  separate  control  facilities  for  each  HOL  or  should  only  one 
exist?  This  study  will  address  these  questions  and  will  provide  my  view  of 
the  proper  answers. 
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Scope  and  Limitations 

Although  much  of  the  background  material  in  this  report  is  commonly 
associated  with  embedded  computer  resources,  the  results  should  be 
equally  applicable  to  control  of  HOL  used  by  the  traditional  ADP  commuriity. 
Too  often  it  is  argued  that  the  split  between  the  embedded  computer 
community  and  the  ADP  community  continues  for  all  aspects  of  computer 
systems.  I believe,  however,  that  the  difference  is  essentially  contained 
in  separate  management  philosophies  and  perhaps  some  requirements  for 
specific  software.  Otherwise,  the  differences  seem  to  be  artificial. 

Thus,  this  report  does  not  differentiate  between  HOL  control  facilities  for 
embedded  computer  systems  versus  ADP  systems. 

There  are  certain  methods  already  established  for  the  control  of  COBOL 
and  FORTRAN,  DOD  Standard  HOL.  These  systems  are  geared  to  national 
standards  and  coordinated  development  as  determined  by  ANSI  and  associated 
groups,  e.g.,  CODASYL.  Thus,  any  DOD  control  facility  that  encompassed 
these  languages  would  have  to  include  established  channels  for  the  control 
of  these  HOL. 

Organization  of  Report 

This  report  begins  with  a quick  look  at  the  general  problems  inherent 
in  computer  software  acquisition  and  use.  It  then  progressively  reviews 
DOD  initiatives  to  solve  these  problems  in  the  area  of  HOL  and  suggests  an 
approach  for  an  area  that  has  not  been  completely  addressed  yet:  HOL 

control  facilities. 
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Section  I is  essentially  a historical  review  of  recent  DOD  actions  to 
improve  the  acquisition  and  use  of  computer  resources  with  emphasis  on  HOL. 


It  also  contains  the  scope  and  limitations  of  this  report. 

Section  II  reviews  the  work  of  the  DOD  HOL  Program  since  it  will 
directly  impact  and  influence  the  functions  and  organization  of  a HOL 
Control  Facility.  The  current  HOL  control  facilities  for  COBOL  and  CORAL-66 
are  also  briefly  reviewed  to  provide  background  on  the  control  of  existing 
HOL. 

Section  III  states  and  explains  the  recommended  funct-ons  of  any  HOL 
control  facility. 

Section  IV  discusses  implementation  issues  and  conclusions  concerning 
the  establishment  of  a DOD  HOL  control  facility.  Topics  covered  include 
its  location  as  an  organizational  entity,  the  merits  of  merging  al  or  some 
portion  of  the  current  DOD  approved  HOL  facilities,  when  the  new  OL  control 
facility  should  be  established,  and  its  relationship  with  the  ARPANET/pro- 
posed  National  Software  Works.  At  the  end,  a summary  of  the  conclusions 
reached  in  this  paper  and  areas  for  further  study  are  stated. 


' SECTION  II 


BACKGROUND 

In  the  first  section  of  this  report  a framework  concerning  general 
DOD  actions  to  improve  the  acquisition  and  use  of  computer  resources  was 
established.  Then  the  focus  shifted  within  this  framework  to  the  value  of 
using  HOL  and  the  need  to  control  HOL  to  insure  optimum  usage.  This  back- 
ground would  be  incomplete  if  we  did  not  explore  more  thoroughly  the  basis 
for  and  the  status  of  the  current  DOD  HOL  Program  as  well  as  the  standard- 
ization, development  and  control  situations  for  other  current  HOL. 

HOL  Proliferation 

Until  the  recent  interim  list  of  HOL  was  published,  there  were 
relatively  few  constraints  on  programming  language  use  in  DOD.  The 
business-oriented  ADP  community  was  required  to  use  COBOL  and  the  scien- 
tific ADP  community  was  required  to  use  FORTRAN.  Communications  software 
and  many  weapon  system  developments  depended  upon  assembly  language.  Some 
weapon  system  software  development  was  done  in  HOL.  The  Air  Force  relied  on 
JOVIAL  (J3),  the  Navy  on  CMS-2  and  the  Army  on  TACPOL  when  HOL  were  used. 

Since  the  benefits  of  using  HOL  were  recognized  and  the  then  current 
HOL  were  felt  to  be  inadequate,  various  additional  HOL  development  efforts 
were  started.  A partial  list  would  include  TACPOL-II,  JOVIAL  (PATRIOT)  and 
PDL  by  the  Army;  SPL/1 , TRIDENT  HOL,  and  CS-4  by  the  Navy;  JOVIAL  J73  and 
JOVIAL  J3B  by  the  Air  Force;  and  COL  by  DCA.  This  proliferation  and  its 
attendant  cost  was  soon  recognized  by  the  Military  Departments  and  DOD.  As 
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a result  during  1974  the  adoption  of  a common  programming  language  for  use 
in  the  development  of  major  defense  systems  was  proposed. 

Common  POD  HOL 

The  ensuing  effort  at  the  joint  level  to  develop  a common  programming 
language  followed  the  traditional  acquisition  process  of  any  system.  The 
need  had  been  established  by  the  Military  Departments  and  the  equivalent  of 
a Study  Advisory  Group  was  established  by  DDR&E.  It  was  called  the  DOD  HOL 
Working  Group.  Its  chairman  was  from  DDR&E  and  its  membership  was  from  the 
Military  Departments,  DCA,  MSA  and  DARPA.  Its  course  of  action  was  to 
establish  the  requirements  for  a HOL,  compare  these  requirements  with  exist- 
ing HOL,  choose  a development  alternac-ve  and  implement  the  chosen  HOL 
approach.  At  the  same  time,  any  other  work  to  implement  other  new  HOL  was 
stopped  by  DDR&E. 

The  first  phase  - requirements  identification  - began  in  January  1975 
with  the  preparation  of  a "strawman"  requirements  document  by  the  DOD  HOL 
Working  Group.  It  was  a preliminary  document  which  primarily  illustrated 
the  level  of  detail  desired  with  incomplete  and  sometimes  inconsistent  re- 
quirements. It  was  sent  to  the  Military  Departments,  other  government  agen- 
cies, industry  and  the  academic  community  for  comment.  The  results  of  this 
review  were  gathered  and  merged  with  the  strawman  to  produce  a more  consis- 
tent and  complete  requirements  document  called  a "woodenman."  Although  this 
document  was  greatly  improved,  it  was  still  tentative.  The  woodenman  was 
again  widely  distributed  for  comment.  The  result  of  this  second  iteration 
of  review  and  consolidation  was  a firm  set  of  requirements  in  January  1976 
called  the  "Tinman."  It  was  the  basis  for  the  next  phase  - comparison  of 
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existing  HOL  with  requirements.  The  equivalent  of  a Milestone  0 approval 
for  the  Conceptual  Phase  was  provided  by  DDR&E  on  10  May  1976  (5), 

Development  alternatives  ranged  from  selection  of  an  existing  HOL,  to 
evolutionary  development  of  an  existing  HOL,  or  to  design  of  a completely 
new  HOL.  Ideally  the  least  costly  approach  would  be  to  select  an  existing 
HOL  that  required  few  or  no  changes.  The  candidate  languages  proposed  for 
evaluation  purposes  could  obviously  not  cover  the  entire  spectrum  of  avail- 
able HOL  since  these  numbered  in  the  hundreds.  A preliminary  screening 
limited  the  candidates  to  existing  appropriate  DOD  HOL,  other  well  known  HOL, 
and  certain  HOL  that  had  special  features  and  technological  innovations. 
Evaluations  of  these  languages  versus  the  Tinman  requirements  were  conducted 
via  six  contracts  as  well  as  by  other  interested  groups.  In  addition  to 
comparing  requirements  to  the  existing  HOL,  comments  on  the  feasibility  of 
modifying  the  existing  HOL  to  bring  it  into  compliance  with  requirements, 
identification  of  unnecessary  existing  features  and  comments  on  the  complete- 
ness of  the  requirements  in  light  of  the  evaluation  were  solicited.  These 
evaluations  were  completed  in  December  1976. 

As  the  evaluation  effort  progressed,  three  other  program  management 
initiatives  were  completed.  The  HOL  Working  Group  was  established  as  a 
formal  technical  panel  under  the  auspices  of  the  Management  Steering  Com- 
mittee for  Embedded  Computer  Resources  (MSC-ECR)  in  mid-1976  (6:2-4).  The 
secono  initiative  involved  the  preparation  and  publication  of  a Program 
Management  Plan  (PMP).  It  was  formally  published  in  January  1977  (7).  The 
third  initiative  was  the  publication  of  the  interim  list  of  DOD  approved 
HOL  (8)  in  November  1976. 
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The  HOL  Working  Group  with  appropriate  consultants  consolidated  the 
results  of  the  various  evaluation  efforts  into  a report  (1:3).  Its 
findings  were: 

Among  all  languages  considered  none  was  found  that  satisfies 
the  requirements  so  well  that  it  could  be  adopted  as  the 
Common  Language. 

All  evaluators  felt  that  the  development  of  a single 
language  satisfying  the  requirements  was  a desirable  goal. 

The  consensus  of  the  evaluators  was  that  it  would  be 
possible  to  produce  a language  within  the  current  state  of 
the  art  meeting  essentially  all  the  requirements. 

Almost  all  the  evaluators  felt  that  the  process  of 
designing  a language  to  satisfy  all  the  requirements 
should  start  from  some  carefully  chosen  base  language. 

Without  exception,  the  following  languages  were  found  by 
the  evaluators  to  be  inappropriate  to  serve  as 
languages  for  a development  of  the  Common  Language: 

FORTRAN,  COBOL,  TACPOL,  CMS-II,  JOVIAL  J73,  JOVIAL  J3B, 

SIMULA  67,  ALGOL  60,  and  CORAL  66. 

Proposals  should  be  solicited  from  appropriate  language 
designers  for  modification  efforts  using  any  of  the 
languages  PASCAL,  PL/ I,  or  ALGOL  68  as  base  languages  from 
which  to  start.  These  efforts  should  be  directed  toward 
the  production  of  a language  that  satisfies  the  DOD  set 
of  language  requirements  for  embedded  computer  applications. 

At  some  appropriate  time  some  choice  should  be  made  among 
these  design  efforts  to  determine  which  are  most  worthy  of 
being  continued  to  completion. 

It  should  also  be  noted  that  as  a result  of  these  evaluations  and  other 
inputs,  a new  requirements  document  was  produced  called  the  Ironman  (10). 

It  was  prepared  in  the  form  of  a language  specification. 

These  results  were  presented  to  the  MSC-ECR  at  the  end  of  January 
1977.  Approval  to  proceed  with  parallel  design  efforts  was  received.  This 
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could  be  considered  the  equivalent  of  Milestone  1 approval  to  proceed  into 
the  Validation  phase  of  a major  system.  Present  efforts  are  centered 
around  completion  of  a procurement  package  for  parallel  design  efforts, 
release  of  the  RFP  and  source  selection.  Currently  the  HOL  control 
facility  for  this  effort  is  scheduled  to  be  established  in  August  1978, 
based  on  the  results  of  establishing  control  facilities  for  the  interim 
DOD  approved  HOL.  Some  of  these  control  facilities  are  in  the  process  of 
being  established  now. 

COBOL  Standardization  and  Control 

COBOL  is  a language  on  the  interim  list  of  DOD  approved  HOL.  Since  it 
is  a language  that  is  subject  to  national  standards  efforts,  its  control  is 
different  from  DOD-unique  HOL.  The  American  National  Standards  Institute 
(ANSI)  publishes  a standard  defining  document  as  per  the  approval  of  its 
Committee  on  Computers  and  Information  Processing  (X3)  which  consists  of 
government,  industry  and  other  users.  A technical  committee  for  COBOL 
(X3J4)  recommends  the  initial  standard  and/or  a major  revision  to  the 
standard.  Again  this  technical  committee  has  representatives  from  govern- 
ment, industry  and  other  users.  The  latest  standard  was  promulgated  in 
1974  (ANSI  X3. 23-1974). 

U.S.  Government  standards  in  this  area  are  promulgated  by  the  National 
Bureau  of  Standards,  Department  of  Commerce.  They  are  known  as  Federal 
Information  Processing  Standards  (FIPS).  The  FIPS  publication  for  COBOL 
(FIPS  PUB  21-1)  cites  the  ANSI  COBOL  standard.  It  also  specifies  policy 
for  Federal  government  use  of  the  HOL.  This  in  turn  is  implemented  and 
broadened  by  DOD  Directive  and  Military  Department  regulations.  In 
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particular,  DOD  through  the  Navy  operates  a Federal  COBOL  Compiler  Testing 
Service  (FCCTS)  to  validate  that  COBOL  compilers  indeed  meet  the  ANSI  COBOL 
Standard.  A COBOL  compiler  must  now  be  validated  before  it  can  be  procured. 

Development  of  the  COBOL  language  is  done  by  an  organization  called 
the  Programing  Languages  Committee  (PLC)  of  the  Conference  on  Data  Systems 
Languages  (CODASYL).  This  committee  has  representatives  from  government, 
industry  and  other  users.  The  results  of  its  deliberations  are  published 
in  the  CODASYL  COBOL  Journal  of  Development.  This  journal  is  the  primary 
basis  for  the  deliberations  of  the  ANSI  committee  for  standards  changes. 

The  Military  Departments  have  representatives  on  both  the  ANSI  and  CODASYL 
committees. 

CORAL  66  Standardization  and  Control 

CORAL  66  was  developed  at  the  Royal  Radar  Establishment,  United  King- 
dom (UK)  in  the  1960's.  It  was  established  as  the  standard  programming 
language  for  real-time  systems  and  computers  in  weapon  systems  in  1970.  It 
was  adopted  as  an  English  national  standard  in  1973.  It  has  gained  wide 
acceptance  in  the  English  commercial  sector  for  similar  type  programming. 

It  is  supported  by  the  Department  of  Industry  as  well  as  the  Ministry  of 
Defence  (MOD). 

The  MOD  has  a controlling  body  similar  to  the  DOD  MSC-ECR  called  the 
Interestablishment  Committee  on  Computer  Applications  (lECCA).  The  Royal 
Radar  Establishment  has  a Computing  Standards  Section  which  serves  as  the 
Control  Facility  for  CORAL  66.  In  turn  the  CORAL  66  group  is  a combined 
users  and  implementors  group  (12:3-9).  Much  of  the  organizational  structure 
and  historical  development  of  CORAL  66  has  been  helpful  in  the  DOD  HOL  effort. 
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DOD  HOL  Standardization  and  Control 


I 


i 

I 


1. 

► 

t 


The  interim  list  of  DOD  approved  HOL  are  standardized  and  controlled 
in  two  ways.  The  first  is  via  DOD  affiliation  with  national  efforts  such 
as  explained  previously  on  COBOL.  FORTRAN  standardization  and  control  is 
similar.  The  second  concerns  DOD-unique  HOL  where  individual  military 
departments  have  published  appropriate  defining  documents  and  have  been 
appointed  as  control  agents.  In  essence  each  military  department  is 
creating  separate  HOL  facilities  for  the  languages  under  their  cognizance. 
Project  Manager,  Army  Tactical  Data  Systems  (PM,  ARTADS)  is  establishing  a 
control  facility  for  TACPOL.  Naval  Air  Systems  Command  (NAVAIR)  is  estab- 
lishing a control  facility  for  SPL/1.  Naval  Electronics  Systems  Command 
(NAVALEX)  is  establishing  a control  facility  for  CMS-2.  Air  Force  Systems 
Command  is  establishing  its  control  facility  for  both  dialects  of  JOVIAL 
(2)  at  the  Rome  Air  Development  Center. 

While  there  is  some  dialog  between  the  Military  Departments,  each  of 
these  HOL  control  facilities  will  be  established  differently.  Some  will 
only  emphasize  maintenance  of  the  HOL  as  it  is,  others  will  pursue  develop- 
ment of  the  HOL,  and  still  others  may  emphasize  other  HOL  related  tool 
development.  At  the  same  time  if  the  DOD  HOL  program  is  going  to  establish 
an  HOL  control  facility,  should  it  copy  an  existing  facility  or  pursue  some 
optimum  set  of  functions?  The  documented  organizational  structures  and 
functions  of  control  facilities  for  COBOL,  FORTRAN,  CORAL  66  etc.  and  the 
emerging  HOL  control  facilities  for  DOD  approved  HOL  can  serve  as  a basis 
for  my  perception  of  an  HOL  Control  Facility. 
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59-... 


13 


SECTION  III 


ORGANIZATION  AND  FUNCTIONS 

Mission 

An  HOL  Control  Facility  is  an  organizational  entity  composed  of 
procedures,  personnel  and  facilities  to  manage  and  control  a high  order 
language  and  its  associated  libraries,  translators  and  other  related 
tools  throughout  their  life  cycle.  Its  mission  is  to: 

1)  insure  HOL  stability  via  standardization  procedures. 

2)  develop  and  maintain  state-of-the-art  translators,  related  tools 
and  libraries. 

3)  promote  the  use  of  the  HOL. 

4)  foster  long  term  research  and  development  in  HOL. 

Organization 

After  a careful  review  of  the  many  functions  possible  for  an  HOL 
Control  Facility,  they  have  been  grouped  in  accordance  with  the  organiza- 
tional chart  at  Figure  II.  There  are  two  types  of  relationships  indicated 
on  the  chart.  The  first  type  is  the  organizational  elements  of  the 
facility  itself  which  are  connected  hierarchically  by  solid  lines.  The 
second  is  the  special  groups  not  under  control  of  the  director  which 
either  provide  direct  channels  to  users  and  implementors  or  provide 
independent  means  to  control  the  HOL. 
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FIGURE  II 


ORGANIZATIONAL  CHART 


Special  Groups 
Ihe  y.ser^  Grou£ 

The  users  group  would  consist  of  representatives  from  programming 
organizations  which  develop  applications  software  using  the  HOL  support 
software.  They  would  provide  input  on  problems  with  the  HOL  itself, 
problems  with  compilers  and  other  existing  support  software,  and  needs  for 
new  support  software.  In  turn  information  on  the  current  status  of  HOL 
Control  Facility  development  programs  could  be  presented  and  seminars  or 
other  short  duration  training  could  be  held.  Meetings  would  be  scheduled 
as  often  as  needed.  Occasionally  joint  meetings  with  the  implementors 
group  would  be  held  to  provide  a means  for  exchange  of  ideas  and  informa- 
tion between  the  two  groups. 

Th£  0’^Rl6"’^f'^PI.s_Group 

The  implementors  group  would  consist  of  those  organizations  external 
to  the  HOL  Control  Facility  who  would  be  developing  HOL-related  software 
such  as  translators.  Conceivably  this  could  be  done  by  IR&D  money  of 
contractors,  independent  research  by  universities,  as  well  as  specific  DOD 
contracts  such  as  unique  library  routines  required  by  a program  office.  In 
order  to  insure  conformance  with  standards,  to  receive  feedback  on  problem 
areas,  to  maintain  information  on  special  library  routines  and  to  promote 
academic  use  of  the  HOL,  such  a group  should  be  formed.  Meetings  would  be 
scheduled  as  often  as  needed. 

The  £o£f i^g£r£ti_oji  Co£trol_  ^0£r^ 

Configuration  control  would  be  established  by  tailoring  the  military 
standard  on  configuration  control  (9)  for  computer  software.  The  board 
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would  be  chaired  by  the  Director  of  the  HOL  control  facility.  Its 
membership  would  include  users  and  staff  from  both  the  Operations  and 
Development  elements  of  the  HOL  control  facility.  Configuration 
identification  would  be  maintained  by  the  Operations  element  librarian. 
Valid  change  requests  would  be  received  by  Operations,  preliminary 
analysis  would  be  performed  by  the  Development  element  and  meetings  would 
be  scheduled  by  Operations  depending  on  urgency  of  changes.  Changes 
would  be  reviewed  and  further  analyzed  by  the  CCB.  Its  decisions  on  the 
change,  their  classification,  priority  and  the  rationale  for  the  decision 
would  be  prepared  by  the  librarian  and  disseminated.  Inclusion  of  the 
changes  would  then  proceed  either  by  the  Development  element  or  a 
contractor.  Upon  completion  the  librarian  would  be  informed  so  that 
configuration  identification  could  be  updated  and  its  status  transmitted 
to  all  concerned. 

Functions 

Office_of  ;th£  director 

Manage  all  of  the  activities  of  the  control  facility  - Each  of  the 
organizational  elements  below  the  director  have  been  delegated  various 
functions.  These  will  be  explained  in  detail  for  those  elements.  His 
decisions  affect  internal  policies,  procedures  and  priorities. 

Serve  as  the  interface  to  higher  headquarters  - Advises  higher  head- 
quarters on  matters  affecting  HOL  Control  Facility  and  requests  assistance 
for  support  functions  not  inherent  to  the  HOL  Control  Facility. 

Chair  the  CCB. 


Su^or^ 

This  element  performs  that  set  of  related  tasks  which  support  the 
accomplishment  of  the  assigned  mission. 

Provide  administrative  services  - These  include  operating  a 
distribution  center;  acquiring  regulations,  forms  and  other  external 
publications,  maintaining  a technical  library,  point  of  contact  on  public 
information  matters;  providing  printing  and  duplicating. 

Plan,  budget  and  manage  the  financial  resources  - This  function 
includes  preparation  of  documents  necessary  for  funding  from  higher 
headquarters  as  well  as  internal  control  of  funding  use.  Also  included 
are  manpower  authorization  activities. 

Provide  military  and  civilian  personnel  support  - These  are  the 
traditional  functions  of  .equisitioning  or  recruiting  personnel, 
administering  pay  and  personnel  record  inputs,  controlling  the  preparation 
of  personnel  evaluations  by  appropriate  supervisors. 

Provide  contracting  support  - The  potential  for  contracts  to  do  large 
portions  of  the  control  facility  work  is  high.  Processing  of  the  procure- 
ment package,  monitoring  of  the  contracts  and  coordination  with  contracting 
officers  would  be  provided. 

Provide  facilities  management  - These  are  the  functions  of  allocating 
building  space,  providing  office  equipment  providing  consumable  supplies, 
coordinating  transportation  requirements,  providing  facilities  maintenance. 

Provide  computer  hardware  resources  - This  function  would  depend  on 
the  actual  computer  time  needed  for  the  HOL  Control  Facility  and  the 
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availability  of  external  resources.  Normally,  you  would  expect  that  the 
HOL  Control  Facility  would  tie  in  to  a large  system  via  remote  batch  and 
interactive  terminals.  If  requirements  were  such  that  a stand-alone 
capability  were  needed,  all  the  aspects  of  acquiring  and  operating  a 
computer  facility  would  ensue.  It  is  not  within  the  scope  of  this  study 
to  explore  these  needs  in  detail.  Section  IV  discusses  the  possible  use 
of  the  ARPANET  and  affiliation  with  the  National  Software  Works. 

^p^^ions 

This  element  performs  that  set  of  related  tasks  which  concern  overall 
planning,  control  of  standards,  training  and  day-to-day  contact  with  users, 
higher  headquarters  and  others. 

Prepare  and  publish  an  HOL  Control  Facility  Master  Plan  - This  docu- 
ment would  be  the  basis  for  all  activities  of  the  control  facility.  It 
would  merge  the  financial  and  personnel  planning  of  Support,  the  technical 
planning  of  Development  and  Validation  with  the  day-to-day  work  of  Opera- 
tions. This  document  would  be  updated  periodically. 

Prepare  and  publish  HOL  control  facility  operational  procedures  - Such 
procedures  are  not  only  essential  for  smooth  internal  operations  of  the 
control  facility,  but  also  allow  proper  external  relations  with  users, 
implementors,  contractors  and  higher  headquarters . They  would  cover  much 
of  what  is  being  functionally  described  in  this  study. 

Prepare  and  publish  a formal  HOL  defining  document  - This  document  is 
essentially  the  HOL  specification  which  will  be  used  as  the  standard.  Such 
a document  will  include  a clear  and  unambiguous  definition  of  semantics  as 
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well  as  syntax.  Backus-Naur  Form  (BNF)  is  commonly  used  for  context  free 
syntax,  but  context-sensitive  syntax  and  semantics  do  not  have  such  well 
accepted  forms  of  formal  definition.  Much  work  is  currently  being  done  in 
this  latter  area  (11).  Until  research  is  complete  in  this  area,  one  of 
two  interim  approaches  may  be  feasible.  The  first  is  to  use  a combination 
of  English  and  the  actual  HOL  constructs  themselves  a la  LISP  or  SIMULA  67. 
The  second  is  to  pursue  using  the  best  current  approach  such  as  the 
axiomatic  approach  espoused  by  Hoare  (12:4-12).  This  document  would  be 
periodically  updated  as  changes,  additions  and  deletions  are  approved  by 


the  CCB. 


Prepare  and  publish  user  manuals  for  the  FIOL  and  its  translators  - It 
would  be  nice  if  the  above  defining  document  were  so  clear  that  it  would 
serve  the  user  as  well  as  being  the  standard.  Invariably  this  is  not  the 
case.  A separate  set  of  documentation  should  be  prepared  for  reference 
needs  and  training  programs.  Often  this  takes  the  form  of  a tutorial 
introductory  description  and  a more  formal,  in-depth  description.  These 
documents  wouTU'also  be  updated  as  changes  are  approved  by  the  CCB.  If  the 
HOL  facility  would  provide  access  to  the  HOL  and  its  translator  via  an 
ARPANET/National  Software  Works  approach,  on-line  documentation  would  be 
prepared  and  updated. 

Prepare  and  publish  specifications  and  user  documentation  for 

% 

utilities  and  library  routines  - In  most  cases  these  uti 1 i ties/1 ibrary 
routines  would  be  provided  by  two  sources  - the  internal  development 
activity  of  the  facility  and  users  who  develop  their  own  specific  needs. 
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Those  routines  which  could  be  used  by  it, ore  than  one  user  would  be  docu- 
mented and  controlled  via  the  CCB.  Again  formal  specifications  and  user 
documentation  of  both  hard  copy  and  on-line  types  would  be  needed. 

Establish  and  maintain  an  interface  with  users  - This  function  would 
include  the  establishment  of  a users  group  and  the  sponsorship  of,  as  a 
minimum,  annual  meetings  of  all  users.  A day-to-day  interface  with  users 
concerning  problems  with  the  HOL,  its  translators  and  the  utilities/library 
routines  as  well  as  disseminating  information  and  providing  advice  on  their 
use  is  needed.  A quarterly  newsletter  would  be  prepared,  published  and 
distributed  to  support  this  interface. 

Gather  statistics  and  other  data  as  to  the  use  of  the  HOL  - This 
function  would  include  gathering  data  on  the  translators,  utilities/ 
library  routines  and  other  software  tools  as  well.  Analysis  of  informa- 
tion on  usage  could  indicate  areas  where  optimization  might  be  necessary. 
Analysis  of  information  on  problems  could  aid  not  only  in  their  solution 
but  also  would  help  to  determine  priorities  for  further  work.  This 
function  would  also  include  the  maintenance  of  a complete  file  on  the 
characteristics  of  all  the  users,  e.g.,  computer  hardware  configuration, 
support  tools  in  use,  etc. 

Prepare  and  conduct  a training  program  for  HOL  users  - The  primary 
tool  of  such  a program  would  be  the  aforementioned  user  documentation. 

This  would  be  included  in  an  overall  course  syllabus  along  with  course 
schedules,  teaching  examples  and  problems  and  tests.  Courses  should  be 
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established  for  various  levels  of  programmer  capability,  e.g.,  beginning 
and  advanced,  and  should  cover  translator,  utility/library  routines  and 
other  tools  as  well.  Such  training  would  normally  be  conducted  at  the 
facility,  but  could  be  provided  at  the  user  installation  when  justifiable. 

Establish  a configuration  control  board  - The  agenda  and  meeting 
schedule  would  be  prepared.  The  facility  software  librarian  in  Operations 
would  be  the  primary  interface  for  all  matters  concerning  standards. 
Specific  functions  of  the  CCB  are  explained  above. 

Recommend  POD  policy  changes  concerning  HOL  - This  might  include  such 
areas  as  the  required  information  necessary  for  support  software  in  con- 
tracts for  major  weapon  systems,  i.e.,  required  use  of  a specific  HOL, 
certification  of  vendor  provided  translators,  utility/ library  routines  and 
other  tools,  etc. 

Monitor  a DOD-wide  program  to  insure  compliance  with  standard  HOL. 

Serve  as  a representative  to  national  and  international  HOL  groups  - 
This  function  might  equally  well  be  in  Development.  If  the  emphasis  is  on 
existing  standards  as  part  of  ANSI  work,  it  would  probably  have  a 
representative  from  Operations.  If  the  emphasis  was  on  the  development  of 
an  improved  HOL,  then  Development  would  provide  the  representati >'e. 
y^al^idati£n 

This  element  performs  that  set  of  related  tasks  which  validate  and/or 
verify  that  support  software  for  the  HOL  meet  the  current  standards.  This 
element  should  remain  separate  from  other  elements  of  the  control  facility 


Prepare  a thorough  and  complete  set  of  compiler  validation  tests  - 
These  tests  should  test  all  aspects  of  a compiler  to  include  language 
features,  error  detection,  compliance  with  standard  diagnostics,  and 
implementation  quality  (size,  speed,  object  code  efficiency).  Preferably 
such  tests  could  be  prepared  for  testing  each  compiler  by  a HOL  compiler 
validation  tool  such  as  used  by  the  Air  Force  with  JOVIAL  (2:4-1). 

Test  and  certify  all  translators  for  the  HOL  - Translators  will 
conform  to  the  standard  as  specified  in  the  defining  document  and  will  be 
free  from  known  errors  prior  to  certification  for  use  in  DOD.  Compilers 
submitted  for  certification  (whether  by  the  government  or  vendors)  will  be 
tested  in  a similar  manner.  Test  results  will  be  documented  by  a formal 
report. 

Test  and  certify  utilities/library  routines  and  other  tools  - These 
tools  should  be  written  in  the  HOL.  This  fact  should  help  insure  the 
correctness  of  the  code.  These  other  support  software  tools  would  have  to 
be  validated  against  specifications  like  translators. 

Dey^elo£menJt 

This  element  performs  that  set  of  related  tasks  which  concern  all 
aspects  of  the  actual  development  of  new  support  software  and  maintenance 
of  existing  support  software. 

Prepare  and  publish  a translator  implementors  guide  - This  guide  and 
the  HOL  defining  document  would  provide  translator  implementors  most  of 
the  information  necessary  for  developing  a compiler.  Such  requirements  as 
the  translators  for  an  HOL  will  be  written  in  the  HOL,  designation  of  a 


standard  set  of  diagnostics,  no  subset  or  superset  implementations,  etc. 
(10:23)  are  examples  of  information  in  such  a guide. 

Establish  and  maintain  an  interface  with  implementors  - This  function 
would  include  the  establishment  of  an  implementors  group  and  the  sponsor- 
ship of,  as  a minimum,  annual  meetings  of  all  implementors.  A day-to-day 
interface  with  implementors  concerning  problems  with  implementation  of 
the  translators  and  the  utilities/library  routines  as  well  as  disseminating 
information  and  providing  advice  on  implementations  is  needed.  A portion 
of  the  quarterly  newsletter  would  address  this  area. 

Assess  impact  of  changes,  additions  or  deletions  to  HOL  - This  work  is 
primarily  in  support  of  the  CCB  and  would  be  done  on  changes  to  translators, 
utilities/library  routines  and  other  support  tools.  The  results  would 
also  be  used  to  estimate  cost  and  work  schedules  for  internal  development 
or  contracts. 

Develop  and  maintain  translators  and  other  support  software  - This 
would  include  the  life  cycle  development  and  maintenance  of  compilers, 
ntilities/library  routines,  interactive  source  language  editors  and  symbolic 
debuggers,  test  case  design  advisors,  statistics  collectors,  text  editors, 
loaders,  etc.  (13).  Each  of  these  support  software  tools  would  have 
standard  specifications,  would  be  verified  and  would  be  subject  to  the  CCB 
process  for  changes. 

Identify  a formal  tool  or  method  to  prove  complete  compiler  correct- 
ness - Verification  of  compilers  is  dependent  on  the  state-of-the-art  of  the 
HOL  such  as  an  inherent  assertion  capability  and/or  the  use  of  formal 
semantics  specification  in  the  defining  document.  The  development  of  such 
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a tool  would  not  only  aid  proof  of  compiler  correctness  but  also  program 
correctness.  Current  work  is  only  capable  of  achieving  assurance  of 
partial  correctness  (16  & 17).  This  tool  would  be  used  by  the  Verification 
element  when  complete. 

Establish  a machine  independent  compiler  - In  essence  this  tool  would 
be  some  variation  of  a compiler  writing  tool.  The  tool  would  contain  a 
standard  front  end  (scanner,  parser,  error  handling,  optimization  and 
semantic  routines)  with  a standard  intermediate  language.  The  code 
generator  portion  would  have  to  be  hand  prepared  for  each  target  machine. 
This  system  would  be  available  to  any  hardware  proponent  or  other  developer 
to  construct  compilers  quickly.  Implementation  improvements  could  then  be 
developed  and  incorporated  as  necessary.  Eventually  research  may  even  dis- 
cover a way  to  automate  the  code  generation  portion. 

Sponsor  research  work  to  develop  a new  HOL  - The  state-of-the-art  in 
language  research  is  continually  advancing.  New  HOL  capabilities 
(abstract  data  types)  and  new  computer  architectures  will  eventually 
develop  which  will  make  current  HOL  obsolete.  New  HOL  requirements  that 
cannot  be  incorporated  in  the  current  HOL  must  be  part  of  the  specification 
for  the  next  generation  HOL.  Work  at  academic  institutions  and  elsewhere 
should  be  sponsored  to  develop  new  HOL  capabilities  and  other  related 
research. 
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SECTION  IV 

IMPLEMENTATION  ISSUES  AND  CONCLUSIONS 

Since  the  planning  for  control  facilities  for  existing  HOL  should  have 
largely  been  completed,  the  intent  of  this  study  is  to  focus  on  the  HOL 
control  facility  that  is  intended  to  be  established  in  August  1978  by  the 
DOD  HOL  Working  Group.  The  planning  for  such  a facility  should  begin  now 
if  it  is  to  be  properly  implemented. 

Various  issues  concerning  the  implementation  of  such  a control 
facility  will  arise  before  detailed  planning  can  proceed.  These  issues 
should  be  surfaced  and  eventually  settled.  My  perspective  on  some  of 
these  issues  may  help  this  process. 

Location 

Why  couldn't  the  people  and  facilities  for  the  DOD-unique  HOL  control 
facilities  be  merged  at  one  location?  Wouldn't  such  a merged  facility  then 
eventually  be  able  to  assume  responsibility  for  the  new  DOD  HOL?  Even 
though  the  individual  control  facilities  control  separate  HOL,  many  of  the 
tools  and  much  of  the  work  would  be  similar.  In  many  aspects  the  economies 
of  scale  involved  in  a joint  HOL  control  facility  would  be  less  costly.  A 
properly  sized  computer  facility  would  be  large  enough  to  fulfill  the  most 
sophisticated  requirements,  yet  would  be  less  costly  ihan  use  of 
individually  separate  computer  capability  for  each  HOL.  Overhead  costs 
could  be  reduced  for  administrative  and  support  areas.  Coordinated  re- 
search and  other  overall  planning  would  be  improved.  All  DOD  users  would 
only  have  to  go  to  one  location  for  HOL  support. 


26 


On  the  other  hand  certain  HOL  might  be  de-emphasized  because  of  a 
small  user  base  or  because  of  a comparatively  lesser  capability.  This  is 
not  necessarily  bad  overall,  but  certainly  would  be  for  the  existing  users. 
Centralized  control  at  DOD  level  would  limit  the  control  each  military 
department  now  has  individually.  Since  each  military  department  has  much 
sunk  investment  in  present  software,  it  would  be  loath  to  relinquish  con- 
trol of  their  HOL.  I believe  there  may  be  good  arguments  for  a merger  of 
HOL  facilities  now,  but  that  the  realities  of  present  military  department 
attitudes  would  require  the  continuation  of  separate  HOL  control  facilities 
for  the  present  DOD-unique  HOL. 

The  new  DOD  HOL  control  facility,  however,  can  be  organized  as  a 
joint  facility.  In  fact,  it  must  be,  if  it  is  to  have  users  throughout  the 
DOD  community.  It  should  be  jointly  manned  and  preferably  have  its  own 
computer  resources  for  development  and  validation  of  support  software.  It 
could  be  physically  located  at  any  military  installation  that  had  existing 
facilities  that  could  best  accommodate  the  needs  of  the  HOL  control 
facility.  Organizationally,  to  forestall  factional  problems,  it  should  be 
directly  subordinate  to  DDR&E^ . It  could  have  a relationship  similar  to 
that  between  TRI-TAC  and  DTACCS.  It  would  still  be  guided  by  the  MSC-ECR 
and  its  technical  panel,  the  DOD  HOL  Working  Group. 

^As  of  20  April  1977  0ASD(I&L)  was  disestablished  and  DDR&E  assumed 
responsibility  for  all  acquisition  activities  as  well  as  research  and 
engineering.  Note  that  the  appointment  of  a single  organizational  entity 
at  OSD  level  to  provide  policy  and  guidance  for  all  DOD  computer  resources 
would  be  OASD(C)  if  congressional  guidance  were  followed. 
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Time  of  Establishment 


Even  though  the  target  date  is  August  1978  the  sooner  the  DOD  HOL 
control  facility  is  established  the  better.  Presently  much  of  the  DOD  HOL 
Working  Group  work  is  being  done  part  time  by  military  department  members 
and  other  representatives.  Few  can  be  considered  as  working  full  time  on 
this  program.  Individuals,  even  within  military  departments,  are  separated 
geographically  and  only  interact  together  at  monthly  or  bi-monthly  meetings, 
via  phone  conversations  or  ARPANET  messages.  This  leads  to  improper 
coordination,  long  lead  time  for  working  group  actions,  incomplete 
preparation  of  documents,  procurement  packages,  etc.  Viewed  in  this 
light,  it  is  surprising  that  so  much  has  been  accomplished  thus  far. 

If  this  were  a major  system  in  a military  department,  the  planning 
for  the  organization,  manning  and  facilities  for  a program  office  would 
have  been  completed.  The  program  office  would  have  then  been  established 
during  the  validation  or  prototype  development  phase.  This  is  the  phase 
that  the  DOD  HOL  Program  has  been  in  since  the  end  of  January  1977.  A DOD 
HOL  Facility  which  would  act  in  a manner  similar  to  a full  time  Program 
Management  Office  should  be  established  as  soon  as  possible. 

Internal  Organization  and  Functions 

The  organization  and  functions  of  the  HOL  Control  Facility  were 
specified  in  detail  in  Section  III.  These  functions,  particularly  in  the 
support  area,  would  have  to  be  tailored  dependent  upon  support  provided  by 
the  military  installation  at  which  the  HOL  facility  is  located,  the  number 
of  HOL  that  are  controlled  and  the  relative  priority  of  some  of  the 
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development  activities.  If  the  facility  were  also  to  assume  Program 
Management  Office  responsibilities,  the  initial  manning  would  be  more 
comprehensi ve. 

National  Software  Works/ARPANET 

The  ARPANET  is  a nationwide  computer  network  designed  both  to  explore 
network  technology,  and  to  interconnect  and  service  various  computer 
centers.  Its  key  aim  is  to  allow  the  accessing  of  software,  services  and 
data  from  any  place  in  the  network.  It  is  composed  of  two  sets  of  inter- 

\ 

connected  computer  subsystems.  One  consists  of  the  computers  that  will 
! provide  the  computational  services,  and  the  other  of  the  computers  that 

service  the  communications  needs  of  the  network. 

j 

The  National  Software  Works  (NSW)  will  be  a capability,  resident  on 
the  ARPANET,  intended  to  support  the  development,  use,  maintenance, 

; modification,  verification,  and  storage  of  programs  and  data.  It  is 

principally  aimed  at  the  development  of  software  by  using  available  support 
tools.  NSW  is  intended  to  ease  both  the  administrative  and  technical 
aspects  of  these  activities.  It  provides  mechanisms  for  fiscal  and  access 
; control  in  the  operation  of  software  projects,  and  also  access  and  storage 

convenience  to  programmers  for  the  management  of  their  files. 

The  HOL  Control  Facility  could  use  the  ARPANET/National  Software  Works 
■-  in  a number  of  ways.  Its  own  computer  facility  could  serve  as  a tool 

bearing  host  for  users.  It  could  verify  compilers  on  other  host  computers 
^ of  different  architectures.  It  could  receive  and  send  messages  from  users 

on  the  ARPANET.  It  could  use  its  statistics  gathering  support  software 
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directly  in  conjunction  with  user  operational  software.  Until  the  advent 
of  the  National  Software  Works,  the  existing  ARPANET  would  still  serve  for 
some  of  these  needs. 

Summary  of  Conclusions 

1.  HOL  Control  Facilities  are  not  only  desirable  organizational  entities 
but  are  require.,  for  all  DOD  approved  HOL. 

2.  HOL  Control  Facilities  for  existing  DOD  approved  HOL  should  remain 
separate  and  under  the  cognizance  of  the  appointed  control  agents. 

3.  The  HOL  Control  Facility  for  the  new  DOD  HOL  should  be  a jointly 
manned  and  supported  facility  which  reports  directly  to  DOR&E  with  the 
guidance  of  the  MSC-ECR. 

4.  The  HOL  Control  Facility  should  be  established  as  soon  as  possible  to 
more  effectively  accomplish  the  work  of  the  DOD  HOL  Working  Group. 

5.  The  HOL  Control  Facility  should  be  organized  and  function  as  specified 
in  Section  III. 

6.  The  HOL  Control  Facility  should  use  the  ARPANET  and  become  a part  of 
the  National  Software  Works. 

Additional  Areas  of  Study 

This  study  has  primarily  concentrated  on  the  organization  and 
functions  of  an  optimal  HOL  control  facility.  It  has  also  addressed  some 
other  questions  concerning  the  implementation  of  a DOD  HOL  facility.  A 
detailed  HOL  Control  Facility  Implementation  Plan  should  now  be  developed 
which  would  focus  on  such  areas  as  the  actual  location  of  the  DOD  HOL 
Control  Facility,  exact  number,  grade  and  specialty  of  personnel  to  man 
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the  facility,  the  actual  computer  resources  required  and  available,  joint 
allocation  of  funds  for  the  facility  by  the  military  departments  and  the 
exact  date  the  facility  would  begin  operations. 
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